Hierarchical tunnels, e.g., label switched paths (LSPs), have been used to improve the scalability of tunneling networks, for example Multi-Protocol Label Switching (MPLS) Traffic Engineering (TE) networks. For instance, as the number of nodes and tunnels increases within the network, signaling burdens (tunnel set up/reroute/tear down/resize), resource consumption (e.g., memory), and state maintenance (e.g., refresh, etc.) become increasingly complex and taxing, particularly within network cores. The use of hierarchical tunnels, however, allows for a plurality of tunnels (child tunnels, or “cLSPs”) that traverse a shared path segment (e.g., and have the same or compatible attributes/affinities) to be further encapsulated onto a single hierarchical tunnel (parent tunnel or “hLSP”), which may be less complex and less burdensome to maintain than the plurality of child tunnels.
While hierarchical tunnels offer various benefits that will be understood by those skilled in the art, various technical challenges are also presented with their use. For instance, where a full mesh of hierarchical tunnels is impractical (e.g., where requiring different tunnels for different attributes/affinities multiplies the number of tunnels correspondingly), determining the location of the hierarchical tunnels (e.g., end nodes and a path) and sets of child tunnels to encapsulate/aggregate within hierarchical tunnels can be particularly difficult and inefficient. Currently, hierarchical tunnels may be established (e.g., manually) a priori using estimates of child tunnel locations and needs, but child tunnels may be dynamically created, destroyed, moved, changed, etc. as time progresses, potentially in a way that obsoletes the a priori establishments.